In Part 1 of this three-part blog series we provided an overview of FedRAMP Rev5 changes: why they came about, what they aim to accomplish and – perhaps most importantly – how they’ll drive significant changes in the FedRAMP ATO process, technologies, and expectations. Now in Part 2 we get to dive into three meaty areas that received a significant amount of new attention in the Rev 5 updates for FedRAMP: supply chain risk management, privacy controls and encryption.
Supply Chains Under Fire
As we pointed out in the last post, it’s been a rough couple of years for vendors, suppliers and consumers of digital supply chains. Attacks on the supply chains of Kaseya, Solar Winds, Accellion and other hardware and software providers crippled government and private-sector user alike. Not only did these attacks sow doubt into long-standing assumptions of trust, but they put federal agencies and departments on the front line: attacks on the Department of Justice and the US Patent Office, among others, triggered the Cybersecurity and Infrastructure Security Agency (CISA) to create a special office focused on supply chain security.
NIST (the National Institute of Standards and Technology) also refocused on the security needs of digital supply chains. They released Revision 1 of their Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, with new guidance on identifying, assessing and responding to cybersecurity risks throughout supply chains throughout federal and commercial organizations. But their bottom-line take on applying this updated guidance? “Look to FedRAMP first”.
Among other comments in a NextGov article on supply chain risk, NIST representatives said, “When applying this publication to cloud service providers, federal agencies should first use Federal Risk and Authorization Program cloud services security guidelines and then apply this document for those processes and controls that are not addressed by FedRAMP.”
NIST on supply chain risk: “Federal agencies should first use Federal Risk and Authorization Program cloud services security guidelines.”
This notion of “looking first -to FedRAMP” is reflected in some of the more significant changes to FedRAMP’s R5 instructions, including the introduction of a new “SR” control family for Supply Chain Risk Management. Supply chain risk management was included in Rev 4, but the creation of a dedicated control family in Rev 5 highlights the growing importance of this discipline.
The SR family aims to address the risks “associated with the acquisition, development, and maintenance of information systems and components associated with third-party and vendor services, products, and supply chains.” New controls have been added to existing families to address these risks as well.
All three FedRAMP levels (Low, Moderate and High) are now required to:
- Establish a supply chain risk management plan (SR-1)
- Establish supply chain controls and processes (SR-3)
- Develop methods and tools for asset acquisition (SR-5)
…along with other supply-chain centric control requirements.
And the scope of this supply chain risk management focus? Effectively everything. As SP 800-53 Rev 5 points out, “Supply chain processes include hardware, software, and firmware development processes; shipping and handling procedures; personnel security and physical security programs; configuration management tools, techniques, and measures to maintain provenance; or other programs, processes, or procedures associated with the development, acquisition, maintenance and disposal of systems and system components.”
In other words, these changes cover every facet of digital technology, from design to manufacturing to section and usage and to lifecycle management. Depending on the maturity of an organization’s supply chain risk management program, these changes might require significant new focus in terms of policies, tools, and processes.
Enhanced Privacy Controls
In the past, Federal guidelines like this one from the U.S. Department of Interior would caution that “FedRAMP certification does not encompass Privacy requirements, and each agency is required to meet for cloud hosting applications”. FedRAMP changes that with R5, now requiring data privacy to be considered across a swath of existing controls and control families, including Awareness and Training (AT), Configuration Management (CM), and as part of the System Development Lifecycle (SDLC), among others.
Data privacy has long been an area of concern for federal systems and the way they process, store and handle confidential data. As privacy-focused mandates have taken root in other jurisdictions, notably the European Union’s General Data Protection Regulation (GDPR), US-based bodies and processes like NIST, FISMA, and FedRAMP and have refocused on what “privacy” means in their own specific contexts.
Where in the past “privacy” language was part of several different FedRAMP controls it is now explicit in many and the 800-53 “B” baseline control standard has been written into the testing criteria. Examples of controls where privacy insertions have been made include (but are not limited to):
- AT (Awareness & Training), with addition to these controls: policy and procedures; literacy, training and awareness; role-based training; and processing personally identifiable information
- AU (Audit & Accountability), with addition to these controls: event logging; content of audit records
- CA (Security Assessment & Authorization), with the all-important continuous monitoring requirements: plan of action and milestones (POA&M); authorization; and more
- CM (Configuration Management), with privacy-centric requirements added to impact analysis (CM-4) and change control (CM-3), among other items
- IR (Incident Response) with new or refined privacy requirements in training, testing, monitoring, handling, reporting and other areas
- MP (Media Protection), where privacy requirements are now heightened in both procedures and media sanitization controls
- PL (Security Planning), with new or enhanced privacy requirements around: rules of behavior; architecture; and centralized management
To summarize, a quick review of the NIST R5 summary analysis shows that more than forty controls have been updated to cross-link them to NIST’s 800-83B baseline. This indicates a shift in privacy’s “center gravity” from the FedRAMP perspective: in the past the majority of FedRAMP privacy impacts arose from the Privacy Threshold Analysis (PTA) and the Privacy Impact Assessment (PIA). Now these artifacts have been largely superseded by explicit control references in R5.
Encryption Comes of Age
Encryption is the process of encoding information. This process converts the original representation of the information, known as plaintext, into an alternative form known as ciphertext. Cryptographic modules are the tools that do this work, through a complex combination of hardware, software, and firmware that work together to implement security functions at application, system or service boundaries.
Because of its complexity, encryption can be a stumbling block for CSPs seeking their initial ATO. While their application’s current services may use encryption, FedRAMP requires the use of FIPS-validated or NSA-approved encryption. With Rev 5, FedRAMP has extended this requirement to include ALL data-at-rest (including backups) and data-in-transit (into, through, or out of the boundary). In fact, the requirement applies to all forms of cryptography including “functions such as hashing, random number generation, and key generation…generation of one-time passwords (OTPs) for MFA, and protocols such as TLS, SSH, and HTTPS.”
R5 extends encryption requirements to better cover data-at-rest and data-in-transit scenarios
In the latest FedRAMP updates, CSPs seeking ATO or Ready status from FedRAMP need to detail much more clearly and definitively the cryptographic modules used in their applications and services, even down to the underlying hardware that supports these services. Introduced in June of this year, a new addition to all System Security Plans (SSPs) is titled “Appendix Q: Cryptographic Modules Table.”
The new changes focus on securing not just Data in Use (DIU) but also Data at Rest (DAR) and Data in Transit (DIT). For each of these states Appendix Q needs to capture a significant level of detail for the cryptographic modules in use, including but not limited to:
- Name of module and vendor
- Type of Cryptographic Module Validation Program use to evaluate it, whether embedded, third-party, OS-based, etc
- Where the module is used, such as in the application server, database, volume encryption, binaries, or other areas of the application or service
- Type of encryption provided: file, full disk, record-level, etc
- Hashes, signatures and authentication methods used, such as multifactor, certificate-based, tokens, etc
This level of detail is typically catalogued with on-prem systems, but collecting it for the transient, ephemeral, abstracted services used in SaaS applications and cloud computing has been problematic at best or overlooked at worst. And while these details have in the past been collected by specific requests from specific agencies for specific applications, the practice is now extended – at least in principle – to cover the entire catalog of FedRAMP products and services.
Once again, meeting these requirements could drive significant technical changes to a CSPs services. Some architectures were never designed to be “locked down” to a specific set of cryptographic criteria, and doing so might make some of their features and functions inoperable or unreliable. Organizations should closely review these new requirements and ideally consult with their FedRAMP advisor to ensure all communications and data are properly protected.
In the last installment of this three-part blog series we’ll serve up recommendations and tips from Anitian’s on-staff security and compliance experts about how to navigate the R4-to-R5 transition. We’ll also cover the critical timelines put forth by the FedRAMP PMO.
Join our upcoming webinar! On Wednesday August 23rd at 9:00 AM PST, Anitian compliance engineers will team up with experts from AWS and Carahsoft to present “Seismic Updates: How R5 Brings Foundational Changes to FedRAMP”.
